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ABSTRACT 



Type inference in interactive programming environments falls short in two re- 
spects. The ability to type check definitions one at a time, and to type check some 
definitions but not all after one definition is modified is called incremental on-line 
type inference. Current interactive programming environments perform batch type 
inference and require extensive type recomputation for small changes. 

We give an algorithm for on-line type inference that is implemented as an at- 
tribute grammar. From this grammar an editor was automatically generated that 
performs on-line type inference. 

The editor infers types incrementally due to a well-known reduction we used 
from Hindley-Milner type inference to first-order unification. Unlike other efforts, 
our algorithm for on-line type inference is truly incremental. 
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I. INTRODUCTION 



Interactive programming environments can significantly improve resource uti- 
lization and programmer productivity. Current interactive programming environ- 
ments, however, have not completely resolved some critical issues and consequently 
typically offer limited support for the programmer. Programming environments of 
the future will need to offer much more in the way of language-based support, such 
as type checking. A language-based editor ought to detect and report type errors as 
they occur. The traditional edit-compile-debug-run environment can require hun- 
dreds or even thousands of lines of code to be recompiled for something as trivial as 
a missing semicolon. The problem is that the environment in which the program is 
created typically knows very little about the language being used. It is only when 
the program is passed to the compiler that the programmer receives any feedback. 

An interactive programming environment integrates many of the separate as- 
pects of current programming environments. Type checking in an interactive pro- 
gramming environment is on-line in the sense that definitions may be type checked 
one at a time as they are entered into the system. On-line type checking will pro- 
vide the programmer immediate feedback. This means that at any stage of program 
development the interactive environment will provide feedback about the type cor- 
rectness of the program even if the program is only partially complete. Consider the 
following partial definition for a function that computes the length of a list given in 
Standard ML [Ref. 11] notation: 

fun length 1 = 
case 1 of 
[] => <exp> 

I <pat> => <exp> 
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In the notation for Standard ML “[]” is the empty list. The definition for length is 
not complete (the incomplete term for a pattern is denoted by <pat> and the un- 
specified expressions are denoted by <exp>), yet we may still derive a type according 
to the rules discussed in Chapter II and given in [Ref. 8). The type we can derive 
is Wa.'if3.lista — ► 3. This notation is the standard notation found in [Ref. 8] and is 
discussed in more detail in Chapter II. 

Interactive programming environments exist that perform limited type checking 
but they are not on-line. For a pair or set of mutually recursive definitions, the 
programmer must explicitly provide all the definitions of the mutually recursive set, 
otherwise an error results. This is because environments such as Standard ML use 
an extension of Damas and Milner’s algorithm W [Ref. 8], that is an algorithm 
for the batch type checking problem. A batch type checker reports an error upon 
detecting an unbound identifier. A unbound identifier is one for which no definition 
is provided. The problem is that all the definitions in the sequence must be supplied 
otherwise the batch type checker complains about the unbound identifiers. 

Type checking in an interactive programming environment is an on-line problem 
vice a batch problem. Definitions are type checked one at a time and the type checker 
must not object to undefined free identifiers. Rather, when a definition is provided 
the type checker must ensure that the definition is used correctly. Consider again 
the definition for length given above. We can fill in some of the missing information. 

fun length 1 = 
case 1 of 

□ => 0 

I <pat> => <exp> 

t 

Now we can type the definition of length 'ia.lista — ► inf. As we shall see later, this 
type implies length will accept a list of elements of any type as input and return the 
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length of the list. This type can be determined even though the definition is not 
complete. 

We complete the definition for length so that we have: 

fun length 1 = 
case 1 of 
□ => 0 

I (h::t) => 1 + (length t) 

j 

In Standard ML the notation (h::t) means the concatenation of the head and tail of a 
list. Completing the definition, however, does not provide any more type information 
for length and we are left with 'iot.lista —* int for the principal type of length. 

We propose an extension of W for on-line type checking. (In this thesis 
type checking and type inference are used synonymously.) The model we use is 
a consistently-attributed parse tree specified by an attribute-grammar. Implicit in 
the model is incremental recomputation of types. In addition, recomputing a type 
can be reduced to reunification using a well-known reduction from Hindley-Milner 
style type checking to first-order unification. Unlike other extensions of W [Ref. 13], 
for on-line type checking, our on-line type checker is truly incremental. 
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II. THE HINDLEY-MILNER TYPE SYSTEM 



In this chapter we review the history and basis for our type system. In Section A 
we describe the simply-typed lambda calculus. In Section B we describe the Hindley- 
Milner type system and the grammar for the expressions typed in their type system. 
We will also describe parametric polymorphism and look at an example that shows 
how polymorphic functions are useful. In Section C we look at the type inference 
rules of the Damas and Milner type system. In Section D we review Damas and 
Milner's algorithm W which infers a type for an expression of the grammar given in 
Section B. This chapter puts the thesis contribution in the context of other work, 
namely the simplv-typed lambda calculus, the Hindley-Milner type system, and the 
polymorphic lambda calculus. 

A. THE SIMPLY-TYPED LAMBDA CALCULUS 

The simply-typed lambda calculus has types: r :: = p | r x — ► r 2 . Small greek 
letters are used to represent type variables (type variables have values that range over 
all named and anonymous types definable in a language.) We will use the standard 
notation x : a to mean that the expression x has type cr. In this type system we 
can infer the types of lambda expressions such as: Xx.x : a —* a. We can also type 
more complex expressions such as: (Xx.x) Xx.x : /3 —> /3. 

In the simply-typed lambda calculus, however, we would be unable to type the 
expression, (A y.y y ) Xx.x. The simply-typed lambda calculus fails to infer a type for 
this expression because A in the simply-typed lambda calculus exhibits monomorphic 
abstraction. This means that each instance of y in (y y) must have the same type. 
In order to type (A y.y y) Xx.x, we must be able to instantiate a unique type for 
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each instance of y in ( y y). The simply-typed lambda calculus, however, fails in 
this regard. But the expression (A y.y y) Xx.x reduces to the equivalent expression 
(Xx.x) Xx.x. We have already seen that this expression can be given the type 0 — * 3. 
So we have two expressions that are equivalent but only one may be typed in the 
simply-tvped lambda calculus. 

B. HINDLEY-MILNER TYPE SYSTEM 

The Hindley-Milner type system extends the types of the simply-typed lambda 
calculus with type schemes (quantified expressions of type variables), so now in 
addition to r types we also have type schemes. The complete type system is: 

r ::= p \ t x -> r 2 
a ::= Va.cr | r 

The Hindley-Milner type system is able to infer a more general type than the simply- 
typed lambda calculus. In the Hindley-Milner type system, for example, we can infer 
a more general type for the identity function: Xx.x : Va.a — ► a. 

The Hindley-Milner type system, however, still fails to infer a type for the 
expression (A y.y y) Xx.x , because of the limitation of monomorphic lambda abstrac- 
tion. But the Hindley-Milner type system provides the let expression, that allows 
the equivalent expression: let y = Xx.x in y y ni, to be correctly typed. Let in the 
Hindley-Milner type system exhibits polymorphism and, using their type system, we 
can infer the correct type: Va.a — *• a, for the expression let y = Xx.x in y y ni. 
This is better than the simply-typed lambda calculus in which we could not type the 
expression (A y.y y)Xx.x at all. 

In order to type the expression (A y.y y) Xx.x we need a polymorphic lambda 
calculus, which is beyond the scope of this thesis. A polymorphic lambda calculus 
is a second order calculus that would allow a type for each instance of y in (y y) to 
be instantiated uniquely. 
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e — > x 
\ Xx.e 

| let x = e in e' ni 

Figure 2.1: Expressions in the Hindley-Milner type system. 

The Hindley-Milner type system will infer a type for a single expression. The 
grammar for expressions in the Hindley-Milner type system, shown in Figure 2.1, is 
the lambda calculus with the addition of let expressions. Some authors include an 
additional production to the ones given in Figure 2.1, e — ► c, where c is a constant 

such as true, false, 1, 2 This production is just a special case of e — ► x and we 

will use just the production e — > x where x can be an identifier or a constant such 
as true, false, 1,2,.... 

Lambda abstraction Xx.x is the identity function. By definition, this function 
applied to any argument simply returns the argument. So that if we applied Xx.x 
to true we would get true , and if we applied Xx.x to 1 we would get 1. In the 
Hindley-Milner type system we are able to infer a much more general type for this 
expression. We can now say, Xx.x has type Va.o — ► a, which is more general than 
/?—+/? in the sense that a can be instantiated to any type. 

We can also define more complicated expressions built up from basic expressions. 
For instance, we can define a function first = Xx.Xy.x , which will take as input a 
pair and return the first element of the pair, so if it were applied to (1 2) it would 
return 1. Actually the lambda calculus is curried, which means functions can only 
be applied to a single argument. So the definition we have given for first actually 
takes as input the first element of a pair and returns a function that takes as input 
the second element of a pair. For this function, the value returned would be the first 
element of the two input elements. 
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Similarly we could define a function that returns the second element of a pair: 
Xx.Xy.y, which will take as input a pair and return the second element of the pair, 
so if it were applied to (1 2) it would return 2. 

A conditional expression can similarly be defined: 

Cond = Xx.Xy.Xz.z x y, 

and if we also define True which is defined the same as first, 

T rue = Xx.Xy.x, 

then we could apply 

Cond 1 2 True , 

where we mean: 

((((Xx.Xy.Xz.z x y) 1) 2) True). 

The parentheses have been added to emphasize the fact that the lambda calculus is 
curried and the A abstraction can only be applied to one argument. The order in 
which this may be reduced is: 

(((Xy.Xz.z 1 y) 2) True), 

where the bound occurrence of x has been replaced by 1. Next we may perform the 
following reduction: 

((Xz.z 1 2) True), 

where y has been replaced by 2. Finally we can reduce the expression to: 

((True 1) 2), 

where z has been replaced by True. This can also be reduced as follows: 

((True 1) 2) 

= (((Ax.Ay.x) 1) 2) 

- ((Ay-1) 2) 

1 
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This reduction gives us the expected result. Recall the original expression was 
Cond 1 2 True. If this were expressed as the equivalent If true then l else 2 fi we 
would see the expected result immediately. Since true is always true we get 1 from 
the then branch of the conditional expression just as we would expect. 

Polymorphism in the Hindley-Milner type system is called parametric polymor- 
phism. Functions that operate on parameters of different types are polymorphic. 
Suppose that we could define a function length that returns the length of a list of 
any type. We can say length has type Va.lista — » int adn therefore is polymorphic. 
It returns the length of any list. [Ref. 1: pg. 364] 

Aho, Sethi, and Ullman claim Ada is polymorphic, albeit a restricted poly- 
morphism. It is worth taking a look at an example of what might be considered a 
polymorphic Ada module. Their claim is that generics in Ada are polymorphic. In 
this context generic is an Ada reserved word. It is true that an Ada generic module 
may be compiled without complete type specifications. In order to use such a func- 
tion, however, the generic module must be instantiated at run-time. The generic 
module must be instantiated for each type of list that uses the function length. Thus 
at run-time, an instance of the generic module will exist for every type for which the 
module has been instantiated and each module will be monomorphic. [Ref. 1 : pg. 
364] 

Let’s look at an Ada specification for a generic function length, that will return 
the length of a linked-list of any type. 

generic 

type list is private; 

with function Next (e: list) return list; 

with function Empty (e: list) return boolean; 
function length (1: list) return positive; 
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We must also provide a body for the function. 

function length (1: list) return positive is 
len: positive := 0; 
lptr : list := 1; 
begin 

while not Empty(lptr) loop 
len := len + 1; 
lptr := Next (lptr); 
end loop; 
return len; 
end length; 

This comprises a complete compilation unit in Ada. A bit more work is required 
to use the function length in a program. If we look at the specification for the 
generic function we see that three parameters are required. First, we must know 
how to access the elements of the list so we need a pointer to a list element which 
should contain a field with a pointer to another list element and to be useful at least 
one data field. The second and third parameters are functions which are required 
to manipulate the type of list we have specified in the first parameter. Since this 
is a generic module we have to explicitly provide these functions when the generic 
function is instantiated for a specific list type. For each type of list that uses the 
generic function length, a separate instantiation is required. Each instantiation 
requires separate code for the specific list type. 

At compile time the generic function length could be given type 'ia.lista — ► int 
that leads one to believe generics in Ada may be polymorphic. At run-time, however, 
each instance of length can only have type listr —* int for some particular r. The 
fact that at run-time there exists an instance of the function length for every type 
for which the generic function length has been instantiated means that generics in 
Ada are not polymorphic, and in fact Ada is monomorphic. 

In Standard ML a function that finds the length of a list can be written that is 
polymorphic. 
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fun length 1 = 
case 1 of 

□ => 0 

I (h: :t) => 1 + (length t) 

i 

Length in Standard ML could also be typed Va. list a — ► int and this would hold 
true at run-time as well [Ref. 1: pg. 365]. 

In the Hindlev-Milner grammar the let expression provides let polymorphism. 
If e is polymorphic then in the expression let x = e in e' ni, every free occurrence of 
x in e' can be assigned an instance of the type of e. This implies that each occurrence 
of x in e' may have a different type depending on how each occurrence of x is used 
in e'. 

Different strategies have been proposed for typing let expressions. Damas and 
Milner’s algorithm W handles let expressions by typing the definition of the let- 
bound id and then typing the body of the let expression in an environment that 
includes a generic type for the let- bound id. Here we are using the term generic to 
refer to a type that may be instantiated and not a generic unit in Ada. See [Ref. 4] 
for more about generic types. 

Another strategy is to replace every occurrence of the /ef-bound id in the body 
of the let expression with the definition of the let- bound id. This strategy has a 
disadvantage. If the let-bound id does not occur in the body of the let expression 
then the replacement will not occur. Consequently during type analysis the definition 
of the let- bound id will never be processed. This would allow type errors in the body 
of the let- bound id's definition to go undetected. This is unacceptable under strict 
semantics for let expressions. 
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TAUT: 



A h x : a 



x : a in A 



INST: 

GEN: 

COMB: 

ABS: 

LET: 



Ah_ejjr 
A h e : a' 



Al~e: a 
Ahe: Vacr 



A h e : r 1 -> r A h c' : r 
A h (e e') : r 

AxU{j : t 1 } h e : 7 
A h (Ax.e) : r' — > r 

A h e : cr A T (J{x : cr} h e' : r 
A h (let x = e in e'ni) : r 



cr > a' 



a not free in A 



Figure 2.2: The Rules of the Hindley-Milner type system. 

C. THE RULES OF DAMAS AND MILNER 

The notation used in this paper is that used in [Ref. 8]. Briefly, A is a set of 
assumptions for which the following holds true: A contains at most one assumption 
about each identifier x, and A x is the set of assumptions with no assumption for x. 
We use the notation x : a to mean that x has the type a. Also we use the following 
notation to mean, from the set of assumptions A we can infer type cr, where a is a 
type scheme, for an expression e: A h e : cr. Also, for a and 0, type variables and 
r a type scheme: [/?,•/ a,-] r means to replace all free occurrences of the a,-’ s in r with 
the fa's. Damas and Milner provided the rules shown in Figure 2.2 for type inference 
[Ref. 8]. 
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D. ALGORITHM W 



Damas and Milner gave the following algorithm for typing a single expression 
of the grammar given in Figure 2.1 with respect to an initial assumption set A. W 
returns a substitution S and a type variable r [Ref. 8]. 

\V{A, e) = (S, r) where 

1. If e is x and there is an assumption x : Va 1 ...Q n r / in A then S = Id and 
r = [3 ,/a t ]r' where the 0 t 's are new. 

2. If e is {e x e 2 ) then let IV(A, e x ) = (S x ,t x ) and W(S x A,e 2 ) = (S 2 ,r 2 ) and 
U{S 2 t i, t 2 —> 3) = V where /? is new; then 5 = R5 2 5 i and r = F/3. 

3. If e is Ax.ej then let 3 be a new type variable and W(A x \Jx : 3,e x ) = (5i,Ti); 
then S = S x and t = S \(3 —* t x . 

4. If e is let x — e x in e 2 ni, then let W(A, e x ) = (S x , and W(A, e x ) = (5i, Tx) 
and 1F(5 i A x IJ{x : S'i/1(t 1 )}, e 2 ) = (5 2 , r 2 ); then S = S 2 S X and r = r 2 . 

The substitution S = [/3,/a,] returned by VF must be applied to the type variable 
r, and the resulting r type must closed with respect to the initial set of assumptions 
A. The result is a type scheme for the expression. 

W infers the type for a single expression. There is no implicit mechanism to 
deal with top-level definitions. Any extension of W to a “program” must be done 
explicitly. 

1. Most General Unifier 

Damas and Milner’s algorithm W uses Robinson’s unification algorithm. 
The unification algorithm U has the following property: If U(t, t') returns V, then 
V unifies r and r', i.e., Vt = Vt'. Also, if S unifies r and r', then {/(r, r') returns 
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some V and there is another substitution R such that 5 = RV. V involves only 
variables in r and r' [Ref. 8: pg. 210]. 

The substitution V that we are interested in. is the most general unifier , 
that imposes the fewest constraints on the variables in the expression [Ref. 1 : pg. 
370]. 

2. Principle Type Scheme 

W infers a principal type scheme for an expression. This implies that 
any other type scheme for the expression is a generic instance of the principal type 
scheme. This is dependent on the unification algorithm returning the most general 
unifier [ Ref. 8: pg. 208]. 
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III. ON-LINE TYPE INFERENCE WITH 

UPDATE 



In this chapter we will look at the two key elements of a type checker for an 
interactive programming environment. First, we look at what makes the type checker 
on-line. Second, we look at the effect of an update which affords us an opportunity 
to perform type checking incrementally. 

Interactive programming environments would provide much greater leverage 
to the programmer if the environment had the ability to perform type checking as 
definitions are input to the system, one definition at a time, rather than waiting 
until a series of definitions is complete and then analyzing them for type errors. 
Additionally, given a sequence of definitions that have already been built up in an 
interactive environment, a small change to one definition should not cause the entire 
sequence to be retyped unnecessarily. If the system is well designed it should be able 
to use as much information from previous typings and limit recomputation. 

There are two issues involved. The first is what we refer to as on-line type 
inference. Secondly, we are concerned with the semantics of what an update to a 
sequence of definitions means for the entire sequence. 

Consider defining a function g that uses a function / such that g is free in E. 
If we encode this in Standard ML using let as 

let val f = fn ... in 

let val g = fn ...f... in E 
end 
end 
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then we must pay attention to the dependency. The definitions of / and g are 
sequenced. However, Standard ML does provide simultaneous declarations so we 
could write it as a simultaneous declaration where g is defined first: 

fun g() = . . .f () . . . 
and f () = . . . ; 

E 

But now suppose h is also free in the definition of g. If we don’t include a definition 
for h as well in the simultaneous declaration, then the Standard ML interpreter 
complains that h is an unbound variable or constructor when in fact the interpreter 
could very well infer a type for /. 

The problem is that simultaneous declarations in Standard ML and letrec defi- 
nitions in Scheme are typed in batch mode. That is, all definitions must be supplied 
before a type is inferred for any one of the defined functions. Clearly this is unde- 
sirable in a programming environment where definitions are typically given in any 
order and the need for type analysis begins before all definitions of objects compris- 
ing a system or even a subsystem are present. The problem at hand then is what we 
call on-line type inference. We are proposing a programming environment in which 
definitions can be made in any order and are continuously type-checked. 

A. ON-LINE TYPE INFERENCE 

Type checking definitions, one at a time, is called on-line type checking. If a 
definition, g has been provided and we have inferred a type for g , then when we 
infer a type for / in which g occurs free, we will use an instantiation of the type of 
g to infer a type for /. However, if no definition has been provided for g and we are 
inferring a type for / in which g occurs free then we can give g an instantiation of 
Va.a as necessary in /. This assumption can take place without restricting the type 
of / or <7, nor any loss of generality. This implies that meaningful type analysis may 



15 



take place at any time, and not just when a program or sequence of definitions is 
complete. This also means that if g occurs more than once in /, each occurrence may 
be typed uniquely because the generic type 'ia.a can be instantiated as necessary 
depending on how g is used in /. 

We propose an environment that will infer a type for a definition that may 
contain free identifiers and may possibly be incomplete. Those free identifiers may 
be defined and thus may have an associated type. In the case of a partial definition 
missing elements will be represented by a place holder. Thus the expression will 
be complete in the context where place holders are onsidered valid terms. If a 
definition / contains free identifiers whose types are not known or is incomplete, we 
may still be able to infer a type for /. We will assume that an undefined identifier has 
the most general type Va.a. This can be done without loss of generality, restricting 
the type of any free identifier nor imposing any constraints on the type of a term 
containing place holders. If / contains a free identifier g that has not been defined, 
a type may still be inferred for /. If later a definition is provided for g, then the type 
of / is updated reflecting any changes imposed by the type of g. 

We could extend the grammar given in Chapter II for expressions to include 
place holders: 

e — * < expression > 

x 

e e! 

| Ax.e 

| let x — e in e! ni 

The production e — + < expression > denotes a place holder for an undefined or 
partial expression. This change appears minor, but if we allow such expressions in 
the grammar and are still able to infer a type for the expression then we can infer 
types for partial definitions. 

Recursive definitions are handled using the fixed point combinator Y [Ref. 2: pg. 
164). The fixed point combinator Y has the property that for an expression M, 
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YM = This allows recursive and mutually recursive definitions to be 

typed, but forces the user to use the fixed point combinator Y. 

To demonstrate the handling of mutual recursion, consider defining the func- 
tions even and odd. Using the grammar for expressions given above where we use 
the notation if z x y for the conditional, we first define a function pair : 

pair = Xx.Xy.Xz.z x y 

Next we define functions first and second: 

first = Xx.Xy.x 
second = Xx.Xy.y 

Now we must provide a definition for the fixed point combinator Y : 

Y = A/.(Ax./(x x))(Ax./(x x)) 

Y has the property that (Y M) for some function M is M (YM). Finally, we must 
define a tuple for even and odd: 

P = (Y(Xx.((pair 

(An. (if (= n 0) true ((x second)( — n 1))))) 

(An. (if (= n 0) false ((x first)( — n 1))))))) 

Now we can define even as P applied to first and odd as P applied to second. 

even = ( P first ) 

odd = (P second) 
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Let's look at an example: First, let's rewrite P to make it easier to read 



P = ( YM ) 



where 

M = (A x.((pair 

(An. (if (= n 0) true ((x second)( — n 1))))) 

(An. (if (= n 0) false ((x first) ( — n 1)))))) 

Now we can apply even to a number: 

(even 2) 

- ((P first) 2) 

-> (((YM) first) 2) 

-(((M(Y M)) first) 2) 

-»• ((((Ax. ((pair 

(An. (if (= n 0) true ((x second)( — n 1))))) 

(An. (if (= n 0) false ((x first)( — n 1)))))) 
(YM)) first ) 2) 

-> {(((pair 

(An. (if (= n 0) true (((YM) second)( — n 1))))) 
(An. (if (= n 0) false (((YM) first)( - n 1)))))) 
first) 2) 

— > ((An. (if (= n 0) true (((Y M) second)( — n 1)))) 2) 

— > (((YM) second) 1) 

— (((M(YM)) second) 1) 

-* ((((A x.((pair 

(An. (if (= n 0) true ((x second)( — n 1))))) 

(An. (if (= n 0) false ((x first)( — n 1)))))) 
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(YM)) second) 1) 



-*■ ((((P air 

(An. (if (= n 0) true (((YM) second)( — n 1))))) 
(An. (if (= n 0) false (((YM) first)( - n 1)))))) 
second) 1) 

— > ((An. (if (= n 0) false (((Y M) first)( — n 1))))1) 

(((YM) first) 0) 

(YM)) first) 0) 

— ((((\x.((pair 

(An. (if (= n 0) true ((x second )( — n 1))))) 

(An. (if (= n 0) false ((x first)( — n 1)))))) 
(YM)) first) 0) 

-»■ {(((pair 

(An. (if (= n 0) true (((YM) second)( — n 1))))) 
(An. (if (= n 0) false (((Y M) first)( — n 1)))))) 
first ) 0) 

—> ((An. (if (= n 0) true (((YM) second)( — n 1)))) 0) 

— > (true) 



As expected, even applied to 2 returns true. 

In our type system the definitions we type are partially ordered. Ordered defi- 
nitions and mutual recursion would normally cause a problem. We have a solution, 
however, which is to use the fixed point combinator Y and tuples. The brief exam- 
ple we just looked at demonstrates how a system can implement mutually recursive 
definitions with a tuple and the fixed point combinator Y. Since we can define mu- 
tually recursive definitions using a tuple and Y, the definitions given in a program 
are partially ordered. 
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In an off-line or batch type system, no definition may contain undefined free 
identifiers, otherwise an error results. Standard ML is an off-line type inference 
system. In our system, definitions may have undefined free identifiers and the order 
those definitions are entered is irrelevant. Additionally a definition may not even be 
complete but contain place holders for expressions and the type inference system will 
still return a valid type if one exists. Suppose w r e entered the following definition: 

foo = A< identifier > . < exp >. 

The place holders for an identifier and expression indicate we have not completely 
specified the definition of foo , however, we can still infer a type for foo : Va.Vd.(a — » 
3). Type analysis takes place with no restrictions imposed by the place holders and 
we can infer the most general type for the expression. 

Damas and Milner’s algorithm W infers a type for a single expression. We 
would like to have the ability to type a series of named expressions or a “program." 
A named expression is simply a definition. Typing expressions one at a time allows 
programs to be develop in an incremental top-down fashion. This is not so easy to 
do in batch systems since a free identifier for which no definition has been provided 
causes an error. A batch system forces bottom-up development where all definitions 
must be defined before being referenced. For example, defining g and then / in 
terms of g should be the same as defining / in terms of g and then defining g. In an 
imperative language such as Ada, if we define / in terms of g but have not already 
defined g , nor provided a specification for g, during compilation we will get an error. 
Ada requires that either g be defined or a specification be provided prior to its use. 
Either way, this forces the programmer to worry about how function definitions are 
ordered when in fact ordering functions at the same nesting depth is irrelevant to 
the meaning of the program. 
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B. UPDATE 



In an interactive programming environment there is a unique problem when 
we have a sequence of definitions and we update or modify one of the definitions. 
The effects of an update varies among languages. There are at least four possible 
interpretations for updating a sequence of definitions [Ref. 9]. 

1. An update to a definition supersedes the original definition and is used in all 
subsequent references to the definition but does not change definitions prior to 
the new (updated) definition. This is ML’s interpretation. 

2. An update to a definition is an augment to a partially defined definition and is 
incorporated in all subsequent references to the definition but does not change 
definitions prior to the new (updated) definition. 

3. An update to a definition supersedes the original definition and all references 
both prior and subsequent to the new (updated) definition are changed. This 
is the behavior we desire. 

4. An update to a definition augments the original definition and all references to 
the definition both prior and subsequent to the new (updated) definition are 
changed. This is Prolog’s interpretation. 

Standard ML’s interpretation requires that the user re-enter any definition that 
depends on the modified definition if the effect of the modification should be propa- 
gated. For example, in Standard ML if we have a definition / and then a definition 
g which references /, and then update the definition of / so now we have /', the 
reference to f in g is not changed, and consequently g is not changed either. This is 
not desirable because if there are many other definitions besides g which reference / 
and we want them all to refer to the new definition /', then every definition in which 
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/ occurs free that we want to reference the new definition /' must be re-entered 
after the new definition for /'. A better solution would be to have an environment 
that allows a user “to go back” and modify the original definition. In this sense a 
syntax-directed editor provides the logical framework in which to allow updates to 
be made directly to the original text. Update will now replace the original definition 
and all references to the definition will refer to the new definition. 

Typically for environments like Prolog, Scheme, and Standard ML a file is 
loaded and the entire file is interpreted and any type errors are reported at that 
time. If a definition is to be changed then the file is edited, loaded, and processed. 
So even if the change was small and, only a few definitions needed to be processed, 
the rest of the definitions in the file are processed unnecessarily. The problem is how 
to handle small changes to a large set of definitions with the minimum amount of 
work [Ref. 10]. 

There are two issues that determine the incremental aspects of an update. First, 
if we can preserve information when we type a definition we can reduce the amount 
of work that is necessary to recompute the type of that definition. Assume we have 
a definition / in which g occurs free. A type may already have been inferred for / 
when a modification to g necessitates that / have its type reinferred. If we use as 
much information as possible from the earlier typing of / when its type is reinferred 
then we can type / incrementally. 

Second, if the dependencies are carefully observed only those definitions that 
depend on a modified definition or whose type changes as a result of a modification, 
must be retyped. It is possible to partially order the definitions because we have the 
fixed point combinator Y to handle recursive and mutually recursive definitions. We 
can represent the dependencies a s a pair ( f,g ), that means / depends on g. If we 
have a sequence of definitions with the following dependencies, {(/, < 7 ), (/, h), (h, i)} 
and / were modified, only / would need to have its type inferred. If i were modified 
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then types would need to be inferred for /, h, and i , but not g. So, by observing the 
dependencies we can limit the amount of work needed to infer types for the sequence 
of definitions. 

Since we have an environment that allows the programmer to edit the original 
definition there is no question what a reference to a modified definition should be. 
The original definition no longer exists so any reference must be to the new updated 
definition. This is even more important in an on-line environment where definitions 
may be entered in any order. In / a reference to g may refer to a definition either 
above or below / in the parse tree. The ordering does not matter in the on-line 
environment. So if / references g and g is modified yielding g' the reference in / is 
clearly to g' . 
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IV. ON-LINE TYPE INFERENCE THROUGH 

ATTRIBUTION 



In this chapter we look at a special class of grammars called attribute grammars 
and provide an attributed grammar for on-line type inference. The attribution is 
circular but nonetheless is an on-line type inference algorithm. In Section A we 
look at attribute grammars in general and provide the semantics for the attribute 
equations of an attributed grammar. In Section B we will look at a circular set of 
attribute equations for on-line type inference and discuss the meaning of such a set 
of attribute equations. 

A. ATTRIBUTE GRAMMARS 

A context-free grammar (CFG) is a tuple, G = (JV, S, S, P) where A is a set 
of symbols, S is a set of terminals, S E N is the start symbol, and P is a set 
of productions. This formalization can be easily extended to allow' the symbols in 
( A’ U E) to have values. This extension is a special class of grammars called Attribute 
Grammars (AGs). The names of values associated with a symbol in a grammar 
are called attributes. The attributes for a grammar’s symbols can be divided into 
two categories: inherited and synthesized. Inherited attributes can be calculated 
from parent’s and sibling’s attributes. Synthesized attributes can be calculated from 
children’s attributes and other attributes at the same node. The equations from 
which an attribute’s value is determined are called attribute equations. [Ref. 1 : pg. 
280] 

Formally, an attribute grammar can be expressed as a 5-tuple [Ref. 7]: 

AG = (G, A, VAL , SD, SC). 
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G is a context-free grammar that we just discussed. A is a set of attributes such 
that each attribute a E A ranges over a domain of values denoted by Dom(a). VAL 
is the set of values that an attribute a can assume, 

VAL = { Dom(a ) | a E A). 

Each attribute is associated with a symbol of (AIJE). If A - is a symbol of G then 
the attributes of A are denoted by: 

A x = {X.a | a £ A). 

For each occurrence A,- of a symbol A in a production p there is an attribute instance 
A,. a for all a E A x . For each production p, the set of all attribute instances is: 

A p — {A, -.a | a £ A x and A, £ p). 

A is partitioned into two disjoint sets AI and AS, the inherited and synthesized 
attributes respectively. The inherited attributes of the start symbol must be null, 
AI s = 0- The synthesized attributes of the terminal symbols must also be null, 

AS X = 0 if A G E. 

SD is the set of semantic definitions for the productions of P. 

SD = {SD P | p E P). 

A semantic definition defines the value of an attribute instance in A p . The value 
depends only on other attribute instances in A p . There can be only one such semantic 
definition that assigns a value to an attribute a in A p . Given a semantic definition 
/ : Dom(b 0 ) x ••• x Dom(bk) —> Dom(a), then (A,.a = /(A 0 .6 0 , . . . , A^.t*)) € SD p . 
Thus, semantic definitions are local to a particular production p E P. 

SC is the set of semantic conditions (predicates). There is one semantic condi- 
tion for each production p £ P. 

SC P E Dom(b 0 ) x • • • x Dom(bk) — ► BOOL , bj E A p . 
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P = E 



F 



E+ F 
E-F 
F 



Figure 4.1: Productions for the calculator grammar. 



Production Semantic Rules 



E —y E + F 
E —> E - F 
E-* F 
F i 



Ei.v = E 2 .v + F.v 
Ei.v = E 2 .v — F.v 

E. v = F.v 

F. v = i.lexval 



Figure 4.2: Semantic definitions for the productions in Figure 4.1. 

A sentence S in L(G) is in L(AG ) iff for each use of production p in a derivation of 
S , the values of its attribute instances satisfy SC p . 

Consider the following grammar G, where N = { E , F}, E = i. S = E, and the 
set of productions P is given in Figure 4.1. The grammar defines a calculator for 
the + and — operators. This CFG can be attributed so that we have an attributed 
grammar AG. First, we let the set of attributes for E and F be {v}, so A = {i>}. 
The domain for v is the natural numbers so VAL = Z. The semantic definitions 
are given in Figure 4.2. In Figure 4.2 the notation Fj jefers to the first or leftmost 
occurrence of the symbol E in the production. Multiple occurrences are counted left 
to right. For example, E\.v refers to the attribute named v of the first symbol E in 
a production. If a term E occurs only once in a production its attributes are simply 
denoted E.a. 

The parse tree for this grammar can then be decorated with the value of the 
expressions such that at each node we store the value of the subtree rooted at that 
node. For example, the decorated parse tree for the expression 3 + 7 is given in 
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Figure 4.3: Attributed parse tree for the expression 3 + 7. 



Figure 4.3. [Ref. 1 : pg. 280] 



B. A CIRCULAR ATTRIBUTION FOR ON-LINE TYPE 
INFERENCE 



A special case of an AG is a circular AG (CAG). Non-circular AGs (NCAGs) 
have been found useful in a variety of applications. CAGs, however, have generally 
not been considered useful, and in fact were considered ill-formed and meaningless 
until recently [Ref. 1 : pg. 334] and [Ref. 12]. Semantic equations, for a circular 
attribution, that employ monotonic operators (over some complete partial order), 
define a unique greatest (least) fixed point that may be interpreted as the meaning 
of the circular attribution [Ref. 12]. Sagiv et al. also give an algorithm for converting 
these CAGs to NCAGs [Ref. 12]. 

On-line type inference can be characterized as computing the least fixed point 
of a set of circular attribute equations. We will provide a CAG that is an on-line type 
inference algorithm. The CFG for the language used in our type inference system is 
similar to the grammar used in Hindley-Milner style type system. 

A set of attribute equations is circular if there is a mutual dependency between 
two attributes. When an attribute S.i depends on an attribute S.a and S.a depends 
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T —> P 

P -» D P | D 
D -> /<f = M 

M ^ Id 

| M N 

| A/d.iV 

let /d = M in iV ni 

Figure 4.4: CFG for the on-line type inference system. 



Production 



Semantic Definitions 



T 

P 

P 

D 



P P.inhTE — 0 

DP P\.synTE = D .synTE (J P^. synTE 

Pi-inhTE = D. synTE 
D.inhTE = P\. inhTE (J P 2 - synTE 
D D.inhTE = P.inhTE 

P. synTE — D. synTE 

Id — M D. synTE = {Id, TypeOf(M, D.inhTE)} (J D.inhTE 



Figure 4.5: Semantic definitions for the grammar in Figure 4.4. 

on S.i , where i is an inherited attribute and a is synthesized, the AG is circular. 

The CFG we will use for the on-line type inference problem is given in Figure 4.4. 
The set of attributes for this grammar is A = {inhTE, synTE}. The domain of the 
attributes in A are type environments ordered by subset inclusion. The semantic 
definitions for the CAG are given in Figure 4.5. There are no semantic conditions 
for this CAG, so SC — 0. 

The inherited and synthesized type environment attributes in .4 denoted by 
inhTE and synTE respectively are used to pass the inferred type environment up 
and down the tree. A type environment maps id’s to type schemes. At the node 
for each definition a type will be inferred and then added to the type environments 
being passed up the tree and down the tree. The attribute equations for the pro- 
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I 1 



Figure 4.6: A circular attribution for on-line type inference. 

duction P —> D P add the type of a definition to the inherited and synthesized type 
environment attributes for the symbol P. 

The type environment that is inherited at a node D in the production P — ► D P, 
consists of the types of all the definitions both above and below the node in the parse 
tree. These types are propagated up the tree in P’s synthesized type environment 
attribute and down the tree in P’s inherited type environment attribute. 

In the attribute equation for the production D — > Id = M , the function TypeOf 
returns the principal type of the expression M with respect to the inherited type 
environment D.inhTE. The circularity of this attribution is shown in Figure 4.6. 

A trivial program in this language might look like: 

a = Xx.x; 

b = a\ 

The parse tree for this program is shown in Figure 4.7. The attribute equations for 
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[/ v 

hTE synTE y 3 ? inhTE syr, 




d 4 D inhTE synTE 




i = e 
h a 



Figure 4.7: The parse tree for a = Xx.x and h = a. 



the program shown in Figure 4.7 yield the system of equations in Figure 4.8. The 
least fixed point of a circular set of attribute equations such as the ones in Figure 4.8 
is a solution to the on-line type inference problem. 

A CAG is meaningful if a few conditions are met. By Tarski's theorem if a 
system S is such that all the functions f x are monotonic in all their arguments, 
and all functions are defined over complete partial orders (CPOs) then a fixed point 
exists [Ref. 12: pg. 38]. Unlike Sagiv et al. we're interested in the least fixed point. 

The system of equations in Figure 4.8 can be shown to meet Tarski’s conditions, 
as discussed in Sagiv’s et al.'s work, and thus has a least fixed point, which is a type 
environment providing types for all definitions whose types can be determined in the 
input stream. The right hand sides of the equations in Figure 4.8 can be viewed 
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v^. inhTE = 


0 


(4.1) 


V\.synTE = 


V 2 -synTE [J v 3 .syn.TE 


(4.2) 


v 3 . inhTE = 


V\. inhTE [J v 3 .synTE 


(4.3) 


vi.synTE = 


(a,a—>a) [J u 2 -inhTE 


(4.4) 


v 3 . inhTE = 


V2-synTE 


(4.5) 


v 3 .synTE = 


v 4 .synTE 


(4.6) 


v 4 . inhTE = 


v 3 . inhTE 


(4,7) 


v 4 .synTE = 


if (a,r) £ v 4 . inhTE rmthen 
(b,TypeO /(a, A, v 4 . inhTE)) (J v 4 . inhTE 
else v 4 . inhTE 


(4.8) 


v 5 . inhTE = 


v 4 .synTE 


(4.9) 



Figure 4.8: Semantic equations for program in Figure 4.7 



as functions that compute the value of the attribute given in the left hand side of 
the equations. Equation 4.1 is trivially monotonic because 0 is a constant function. 
Equations 4. 2-4. 4 are monotonic since, Vx.Vy.Vz. x C y => x{Jz C y\Jz therefore 
the union operator (J, is monotonic in both its arguments. Equations 4. 5-4. 7 and 
4.9 are implicitly defined using identity which is monotonic. To show Equation 4.8, 
denoted / 4 . 8 , is monotonic we must show that Vx.Vy. x C y =>• / 4 8 (x) C / 4 . 8 (y) 

Suppose x C. y. Then 

Case I. If (a,r) 6 x =>• / 4 . 8 (x) = xlj{(6, r)}, since x C y then (a,r) £ y =>• 

ftM = y U{(6, t)} 

Case II. If (a, r) ^ x =>• / 4 . 8 (x) = x. If (a, r) € y then / 4 . 8 (y) = y U{(^ T )} ? and 
if (a, r) ^ y then / 4 . 8 (y) = y. In either of these two cases, / 4 . 8 (x) C / 4 . 8 (y). 

The domain of the equations in Figure 4.8 is the power set of the set of all typed 
definitions. If our program consists of definitions for a and 6, then the powerset 
of typed definitions consists of {0, {(a, r a )}, {(b, Tf,)}, {(a, t„), (6, x^)} } which can be 
ordered by set inclusion. The resulting ordering is a CPO shown in Figure 4.9. 
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{(a,T a )} {(6,T t )} 



Figure 4.9: Type environments ordered by set inclusion. 



We are concerned with the least fixed point. If {(a, a — > a), (6, a — ► a)} is 
a solution to the type inference problem for the program a = Ax. 2 ; b = a; then 
{(a, a — ■> a), (6, a — > a), (c, a — » a)} is also a solution, meaning it is also a fixed 
point but it is not the least fixed point. The set {(a, a — » a), (6, a — ► a)} is the 
least fixed point for the semantic definitions of the program in Figure 4.7. 

While we know that the circular attribution given in Figure 4.5 has meaning 
and can be shown to have a least fixed point which can be taken to be a solution 
to the type inference problem, tools exist for NCAGs. Sagiv et al. have a technique 
for transforming CAGs to NCAGs [Ref. 12]. This transformation from a circular 
attribution to a non-circular attribution is being investigated. 

Another, alternative would be to use Farrow’s evaluator generator which is capa- 
ble of accepting a circular attribution and generating a fixed-point-finding attribute 
evaluator. [Ref. 5] 
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V. AN INCREMENTAL ALGORITHM FOR 
ON-LINE TYPE INFERENCE 



In this chapter we present an incremental algorithm for on-line type inference 
that is an incremental type-checker. It is a syntax directed editor, but can be thought 
of as a programming environment. As such, it provides the programmer an envi- 
ronment to evaluate the types for definitions of the form val i = e, where val is a 
keyword to denote a definition. Identifiers i , denote the name of the definition. The 
expressions, denoted by e, have the form we saw in Chapter IV. The definitions all 
have top-level scope much like definitions in Standard ML. Unlike Standard ML, 
however, the scope of the definitions in our programming environment is the entire 
program and not only the rest of the program that appears after the definition. 
Moreover, the order definitions are entered is irrelevant. 

First, we look at an incremental algorithm for on-line type inference. It relies 
on a reduction from the Hindley-Milner type system to first-order unification. The 
remainder of the chapter is devoted to an example that demonstrates the reduction, 
unification and resulting type computations. 

A. THE INCREMENTAL ALGORITHM 

The algorithm is incremental in two respects. First, if the type of a definition 
must be reinferred as much work as possible from the previous typing is used in the 
retyping. Second, only those definitions whose types may have changed will have 
types reinferred. There are three events that may cause a definition’s type to change. 
First, when a definition is input to the system. Second, when a definition is modified. 
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1 



g 




f 

Figure 5.1: Dependency partial order. 

Third, when a definition’s type changes as a result of a change to the type of another 
definition on which it depends. 

If a definition / must be retyped as a result of a new type being generated for 
a definition g, that occurs free in /, we can retype / incrementally if we can use 
some information from the original computation for the type of /. If we observe the 
dependencies we can be even more incremental. For example, if we have definitions 
/, g. h , i, and dependencies {(/, g), (/, h), (h, i)}, shown in Figure 5.1, where (/, g) 
means / depends on g , and then modify the definition of i , we must infer a new type 
for i, since it was modified. In addition, if the type of i changes, we will have to infer 
new types for those definitions that depend on i. But we have to be careful about 
the order in w r hich the definitions are typed after Fs type is reinferred. If we modify 
the initial set of definitions such that i is free in both h and j, then we have the 
dependencies shown in Figure 5.2. Both h and j depend on i , but j also depends on 
h. If i is modified then we may need to infer types for /, h, and j, but w r e must type 
h before / and j because of the dependencies (j, h) and ( f,h ). If we recompute h's 
type and it does not change then only j remains to be typed, not /, even though / 
transitively depends on i, which was modified. 

Before we give the incremental algorithm we must first define some notation. 
Let A be a set of type assumptions mapping the given operators to type schemes. 
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g h 




f j 



Figure 5.2: Direct and transitive dependency for (j,i). 

The operators in the initial assumption set are cons, hd, tl, nil, and Y. Let G (a 
DAG) be the dependency graph for the definitions in the program. Let eqn M and 
Q\f denote the type equations and the type variable respectively, for a term M. 
Construction of eqn M and qa/ is discussed in Section B. We also let TE[v' : a] 
mean update type environment TE , so that v' now has type a. The algorithm uses 
function TypeOf defined by 

TypeOf(M , TE) = let 5 = Unify(eqn M , TE) in 
close(SatM, TE). 

Unify needs a type environment since, as we shall see, eqn M may contain references 
to types of other top-level definitions. TypeOf applies the most general unifier of 
eqn M , to a \ / and then closes the resulting type giving the principal type for M. 
The incremental algorithm is defined below: 

Input: A DAG G of definitions, a type environment TE and a vertex v of G. 
Output: A type environment. 

begin 

Affected = {u} 
while Affected ^ 0 do 

delete the least element v' £ Affected 
let a = TypeOf (M, TE) where v' is defined as term M in 
if <j ^ cr' where v' : o' € TE then 

Affected = Affected \J{x \ (x,v') £ edges(G)} 
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TE = TE[v' : a] 



fi 

ni 

od 

return TE 
end 



Let R be the dependency relation for a set of definitions S. We must compute 
the transitive closure of the dependency relation R. The transitive closure is anti- 
symmetric by virtue of the way mutual recursion is handled using the fixed point 
combinator Y. Therefore the transitive closure is antisymmetric and transitive, and 
thus a partial order say P. We can extend P to a consistent total (linear) order L. We 
write the dependency (x,m) as m < x. For a modified definition m let Affected(m) 
be the set of affected definitions. Affected(m) C S , is defined as {x | (x,m) £ P}. 
So Affected (m) is the set of all definitions that depend on the modified definition 
m. The Affected set is totally ordered by L, so we can recompute the types of each 
definition in Affected in the order given by L. 

We can take the example from Figure 5.2 and again consider what happens if 
i is modified. A total (linear) order for this set of definitions is L — (g,i, h,j, /). 
When the incremental algorithm is called, Affected is set to i. Since i is the only 
element in Affected it is the least element and is removed from Affected. The type 
of i is computed and we will assume the type has changed from the previous type of 
i. Affected is updated to include h and j. The type environment TE is also updated 
with the new type for i. On the next iteration, Affected is {h,j} and since h < j , 
h is the next definition to be retyped. If the type of h has changed, then / would 
be added to the Affected set, otherwise only j' s type remains to be computed. This 
process continues until Affected is empty. 
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E(M,A) = 

case M of 

A x.M : let A' = AU{z >“* 0} 0 new var in 

let (a, e) = E(M,A') in 

( 7 , {e} U {7 = 0 — * a}) where 7 is new 

(M N): let (a, ej) = E(M, A) in 

let (0,e 2 ) = E(N,A) in 

( 7 > {ei } U{e 2 } U{<* = 0 -> 7 }) 7 new 

x : if rc : Va.r G A then 

let t' = [/?i/a,-]r where 00s are new in 
(7 , {t' = 7 }) where 7 is new 

else 

= /?}) new 

Figure 5.3: Algorithm E , to generate the type equations for an expression. 

B. REDUCTION 

Note that TypeOf uses cxm an d e<l n M produced for a term M . The latter is a 
set of type equations corresponding to an instance of first-order unification. This 
instance is obtained by a well-known reduction from type inference to unification 
[Ref. 14]. The ocm is a type variable to which the most general unifier can be applied 
to get a principal type for M . The reduction is achieved by algorithm E of Figure 5.3. 
It takes a term M and an assumption set A as input and returns a pair (qm, eqn M ), 
where is a type variable and eqn M is an associated set of type equations for M . 
The type obtained by closing the application of eqn M 's most general unifier to a\i 
is the principal type of M. 

The notation t x means the type of the definition for x. In E we generate type 
equations where t x stands for the type of x. When we unify the equations for a 
definition say y in which x occurs free we must instantiate the type of x and replace 
each occurrence of t x in the type equations for y with an instantiation of the type 
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of x. Since the definitions will be partially ordered we know we w'ill have already 
typed the definition for x prior to typing the definition for y if x occurs free in y, 
thus we will be able to instantiate the type of x for each occurrence of t x in the type 
equations of any definition y. each occurrence getting a new instantiation. 

The correctness of algorithm E can be stated as follows: Suppose E{M,A) = 
eqn M ), where M is a let-free expression, A is a set of type assumptions, is 
a type variable, and eqn M is a set of type equations. Then S' is a unifier of eqn M iff 
.4 b M : Sa M . 

1. Algorithm L - Lifting Let Expressions 

To build the type equations necessary for unification we must first deal 
with let expressions. Algorithm E does not handle let expressions. The system 
proposed by Wand and O’Keefe also ignores let expressions [Ref. 14]. Cardelli’s 
system handles let expressions in the same fashion as Damas and Milner [Ref. 4] 
[Ref. 8]. Their strategy, however, is not suitable for an on-line environment. Typing 
the /ef-bound id’s definition and then typing the body of the let expression will not 
work in an environment with top-level definitions, because a /ef-bound id's definition 
may contain free identifiers. To meet the requirements for being on-line, a /ef-bound 
id’s definition would have to be partially ordered, along with the rest of the top level 
definitions and typed accordingly. 

In order to handle let expressions we need a different strategy. To construct 
the equations necessary for unification, we must lift the let expressions from the terms 
of our programs so that all our expressions are /ef-free. 

There are two considerations that determine how let expressions must be 
handled. First, we require let expressions to exhibit polymorphism. This requirement 
implies that each occurrence of a /ef-bound id in the body of the let expression is 
not restricted to the same type. Each occurrence of a let- bound id may be used 
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val a = let x = y in x 2 ni 
val y = A z.z 

Figure 5.4: Free identifier in a /e<-bound definition. 

uniquely, and thus may have a unique type associated with it. 

Second, we must allow for top-level naming that implies a definition may 
contain free identifiers. In the Hindley-Milner type system a type is inferred for a 
single expression that may also contain free identifiers, but those free identifiers may 
not refer to another top-level expression. A limited form of naming is permitted 
in the Hindly-Milner type system using let expressions. Thus in our type system 
where a free identifier may occur anywhere in the expression including a /e<-bound 
id’s definition, we have to treat let expressions differently. 

For example, consider the trivial program fragment in Figure 5.4. There is 
a dependency in a on y. We only consider the free identifiers in a when we determine 
the dependencies. The /ef-bound id x is not free in a. But, we must consider any 
free identifier in a even in the definition of the /et-bound identifier. If we were to 
infer a type for the let - bound id x and then type the body of the let expression using 
the reduction technique we are proposing then we would have to apply the results 
of typing x to the typing of the body of the let expression. 

The solution, when we have an expression let x — e in e' ni, is to replace 
each occurrence of x in e! with e. This allows us to maintain let polymorphism and 
deal with top-level naming. If a let - bound id’s definition contains free identifiers, 
the substitution of e for x in e' will introduce a free identifier in the body of the let 
expression, which we know how to handle, and eliminate the necessity of applying 
the results of one typing to another. 

This strategy has the disadvantage that if the let - bound id does not occur 
in the body of the let expression then the definition of the let - bound id will not be 
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L(exp, env ) = 

case exp of 

x: (x, exp') € env ? exp' : exp 

X x.M: Xx.L(M) 

( M N): ( L{M ) L(N )) 

let x = M in N ni: L(N, env[x i— >• L(M, env)\) 

end case 

Figure 5.5: Algorithm L, lifts the let expressions from the definitions. 

typed. We could get around this limitation by forcing the equations for the definition 
of the let- bound id to be included with the equations for the let expression’s body 
and unified regardless whether id is referenced. 

We have an algorithm L shown in Figure 5.5 which simply replaces each 
occurrence of a let- bound id in the body of the let expression with the /et-bound 
id’s definition. L takes as input an expression and an environment which consists of 
pairs of /et-bound identifiers and their definitions and returns a let- free expression. 
The environment is initially empty. The algorithm recursively calls itself until all the 
terminal nodes have been reached. When a let expression is encountered a binding 
is added to the environment and the body of the let expression is processed using 
the new environment. 

2. EXAMPLE REDUCTION AND UNIFICATION 

In this section we present an example that demonstrates the type checker 
in action. We look at the type equations that are generated by E and the final types 
for the definitions. The final types are inferred by unifying the equations returned 
by E, applying the substitution that is returned by unification, and closing the type. 

Suppose we enter the following definition: 

g = Xy.Xz.cond z nil (/ y) 



40 



In g cond and / are free, and no definition is provided for them yet. Also free in g 
is nil which is defined in the initial assumption set and has type Wa.lista. E will 
return an associated type variable and a set of type equations. In these examples we 
will show the sub-expression from which the type equation was generated next to the 
type equation. For g , the type variable returned by E is £, and the type equations 
that get generated by E are: 



Subexpression 


Type equation 




cond 


Icond — ^ 


(5.1) 


z 


II 


(5.2) 


cond z 


L — 9 — > K 


(5.3) 


nil 


list rj = ( 


(5.4) 


( cond z) nil 


II 

1 


(5.5) 


f 


tj = 6 


(5.6) 


y 


a = 7 


(5.7) 


fy 


6 = 7 — *■ e 


(5,8) 


((cond z) nil ) (f y) 


A = e — * y 


(5.9) 


Xz.((cond z) nil ) (/ y) 


T 

II 


(5.10) 


Xy .Xz .((cond z) nil) (f y) 


Z = ct-*v 


(5.11) 



Unification of the type equations yields a substitution that when applied to £ and 
then closed gives us the type Va.V 7 J.V 7 . (a — > (/3 — » 7 )) for g. 

If we continue and provide a definition for cond = Xx.Xy.Xz.z x y, E will 
return the type variable /? and the following type equations for cond: 

Subexpression Type equation 
2 e = rj 
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X 


a = 9 


Z X 


rj = 0 


y 


7 = K 


( z x) y 


i — K ■ 


X z.(z x) y 


C = e- 


Xy.Xz.(z x) y 


8 = 7 


Xx.Xy .Xz.(z x) y 


P — a 


.V/?.V 7 .(a ^ (P- 


►((«-> 



retype g since we now have a new type for cond. All that is required, is to reunify 
the type equations given above for g, only this time we will be able to instantiate 
the type for cond. and not have to use an instantiation of the assumption Va.a, for 
the type of cond. This, however, does not change the type of g. 

Suppose we define / = Xx.x. This definition will cause g ' s type to change. 
The type variable for / returned by E is 7 and its type equations are: 



Subexpression 

x 

Xx.x 



Type equation 
a = P 
7 = a fi 



The type of g is now Va.V/3.V7((a — ► ( list P — *• 7)) —* (a — ► 7)). 

But if we change the definition of / to / = Xx.nil , we will get a type error 
for g. The type variable for / returned by E is 7 and its new type equations are: 



Subexpression 

nil 

Xx.nil 



Type equation 
list ct = P 

7 = 8 -> p 
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This changes the type of / to Vq.V/?.q — ► list (3, that causes unification to fail on 
g's type equations. When g's type equations are reunified Equation 5.1 gives us 
t = (7T — >■ (p — »• ((x — ► (p — ► <x)) — ► <t))). From Equation 5.3, « = (/>—► ((x — »• 
(p — ► <r)) — > <r)). Equations 5.4 and 5.5 give us A = ((x — * ( list g — >• cr)) — ► a). In 
Equation 5.6 we must instantiate the type of /. This will give us 6 = r — ► list <j>. 
Then from Equation 5.8 we find t — list <f>. Finally, when we try to unify Equation 5.9 
we find we have to unify list <j> with (x — * (list g — ► <r)) which fails. As a result-# 
exhibits a type error. 

C. THE SYNTHESIZER GENERATOR 

We have implemented an on-line type checker using a tool called The Synthesizer 
Generator (SynGen) [Ref. 6]. This tool was chosen for its ability to rapidly produced 
a syntax directed editor with an X-Windows interface. The language used in SynGen 
is the Synthesizer Specification Language (SSL). 

There are three main parts of a specification in SSL. First, is the abstract 
syntax for the underlying language of the editor. The second part is the attribution 
and the accompanying attribute equations. Lastly, are the unparsing rules which 
determine how the program’s parse tree is to be traversed. Part of the unparsing 
rules also determine what is displayed at each node and what the user is allowed to 
edit. The unparsing rules also control how expressions and terms are input to the 
system. 

Unfortunately, SSL does not allow circular attribute equations. In order to get 
around the limitations of SSL we chose to perform the type inference at the root 
of the parse tree. This is a change to the circular attribution given in Chapter IV. 
The abstract syntax used in our implementation looks quite similar to that given in 
Figure 4.4. A program is simply a list of definitions or bindings of identifiers and 
expressions of the lambda calculus (with the addition of let expressions). 
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An attribution is provided in our implementation that is used to pass up the 
tree the type variables and type equations generated by E for each definition. The 
attribution also passes a type environment back down the tree. At the node for each 
definition the type variables and type equations are generated by E and passed up 
the tree. At the root, types are inferred for the definitions and a type environment 
is passed back down the tree. Then at the node for each definition a lookup is 
performed on the environment that is being passed down the tree and the type for 
the current node is pulled from the environment and displayed. 

There is another significant optimization we would like to be able to make, but 
is not possible in the framework of SSL. Given a sequence of definitions 
and a set of dependencies (/, g), (g, h),(h,i), . . . , and h is updated, we would like to 
be able to infer a type for only h and those definitions that transitively depend on h, 
in this case g and /. Unfortunately SSL does not provide any mechanism to detect 
whether a parse tree has been changed, so we end up reunifying the type equations 
for all definitions. This is undesirable but the implementation is still incremental to 
the extent the type equations are not regenerated. This is strictly a limitation of 
SSL. 

To demonstrate the interface generated by SynGen a brief example is shown in 
Figures 5.6 through 5.18. Figure 5.6 shows the programming environment at start 
up. The top pane is a message pane. The middle pane is the editing window for 
the defined language. The bottom pane is a context aid that shows at what node 
of the parse tree the cursor is currently resting. The context pane also shows some 
available transformations of the current node which would take the user one level 
deeper in the parse tree. The displayed transformations are up to the editor designer 
so additional transformations may be defined but not displayed. 

Figure 5.7 shows the editor after the context has been changed to def list. A 
program consists of a set of assumptions and a list of definitions. The user-input 
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assumption set may be null but there will be a place holder shown in the editor 
•window. 

In Figure 5.8 the cursor has been placed on the place holder for a definition. As 
you can see the context has changed to a def list. When the context selection def 
in Figure 5.8 is made the definition place holder is transformed to the place holders 
for an identifier and expression as is shown in Figure 5.9. The keyword val and the 
symbol “=” are also inserted. 

The definition has been named g and the context has been moved to expres- 
sion in Figure 5.10. Once the definition is named the type is displayed. Note that 
g is given the universal type Va.a. The reason no type is provided until the defi- 
nition is named is due to the fact that the display routine does a lookup based on 
the definitions name in the type environment. The available transformations for an 
expression are shown in the context pane at the bottom of the window. The ex- 
pression can also be just an identifier although this transformation is not explicitly 
listed. The displayed transformations are up to the editor designer. Optional input 
modes permit a very flexible combination of explicit and implicit input modes that 
make the editor as rigid or as flexible as the designer wishes. One extreme would be 
to force the user to explicitly enter all input with a mouse making selections from 
the context pane while the opposite extreme allows a syntactically correct expression 
to be entered from the keyboard. This allows for a friendly interface that does not 
require explicit mouse selection for every program transformation. 

Figure 5.11 shows the editor after the expression has been transformed to a A 
abstraction. Figure 5.12 shows an identifier entered for the A abstraction and the 
context advanced to the expression. 

In Figure 5.13 a second lambda abstraction has been entered. Figure 5.14 
shows the identifier for the second lambda abstraction and the context advanced. 
Figure 5.15 shows the rest of the definition for g. The free identifiers in g are cond, 
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Figure 5.6: The initial view of the syntax directed editor. 

nil , and /. Recall nil is one of the built in operators with type Va.lista. 

In Figure 5.16 the definition for cond has been entered. Providing a definition 
for cond causes g ' s type equations to be reunified but the type of g is not changed. 

In Figure 5.17 / has been defined as the identity function. This change causes 
g ' s type equations to once again be unified and a new type for g is inferred. This 
time the type of g does change to reflect the constraints imposed by the type of / 
and nil. 

The final display in Figure 5.18 shows the effects of redefining / such that it 
causes g ' s type equations to be reunified. This time, however, the unification process 
fails due to the inconsistent use of / in g and the type system returns a type error 
for g. 
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Figure 5.7: The view when the context def list is selected. 



1(3 ‘untitled* 



m 



File Edit View Options Structure Text Help 



]<A3suxptions> 

I <defimtion> 

lie 

‘I Type • ? 



Context: d«f List 



ED 



Figure 5.8: The view when the cursor is placed in the first definition. 
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Figure 5.9: The view after the context def is selected. 
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Figure 5.10: The view when the definition is named g. 
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Figure 5.11: The context fun has been selected and the place holders for a A expres- 
sion have been inserted. 



|B -^titled* aj 




Figure 5.12: The identifier for the A abstraction has been entered and the context 
has been moved to the expression. 
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Figure 5.13: A second A abstraction is entered. 
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Figure 5.14: The identifier for the second A abstraction has been entered and the 
context has been moved to the expression. 
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Figure 5.15: The rest of the definition g has been entered. 
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Figure 5.16: The definition for the conditional cond has been entered. 
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Figure 5.17: A definition for / has been entered and g's type has changed. 
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Figure 5.18: The definition for / has been changed causing g to be retyped resulting 
in a type error for g. 
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VI. RELATED WORK AND CONCLUSIONS 



We have shown that on-line type inference, an essential element of any in- 
teractive programming environment, is possible using an attribute grammar. Our 
type system obtains typings consistent with the Hindley-Milner type system. Type 
checking is performed on-line and incrementally. Modular, top-down program devel- 
opment is possible and the type system maintains correct typings for each definition 
at every stage of program development. 

The on-line type inference problem can be reduced to that of first order uni- 
fication on a set of type equations. We use the well known reduction from the 
Hindley-Milner type system to first order unification. The reduction generates type 
equations for each definition. The type equations can be saved and used in future 
typings for the definition which would then just require reunifying the type equations. 
The type equations will not change unless the expression is modified (by editing), at 
w'hich point the type equations would be reconstructed. 

The algorithm is incremental because we can save the type equations and only 
reunify the type equations when we must reinfer the type for a definition. Addition- 
ally, the attribute grammar model we propose has a certain degree of incremental 
attribute re-evaluation implicit in the model. Significant additional savings are pos- 
sible if the dependencies of the definitions are observed. The dependency relation is 
a partial order and thus we can generate a total (linear) order. For a modified defi- 
nition we must retype only the modified definition and those definitions that depend 
on the modified definition. 
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A. RELATED WORK 



MIT’s Id programming environment is the current state of the art. Our type 
system is more incremental because we take advantage of the reduction from the 
Hindley-Milner type system to first-order unification. Any time a definition’s type 
must be reinferred we only have to reunify its type equations. The Id environment 
calls W from the Hindley-Milner type system which does all the work of constructing 
and unifying the type equations for an expression every time it is called. 

B. FUTURE WORK 

This thesis will serve as the basis for further research aimed at ultimately de- 
veloping a type discipline for a class of implicitly type imperative programming 
languages in an interactive programming environment. 

One issue we have not addressed in this paper is what happens if more than 
one definition is entered with the same name. In a syntax directed editor environ- 
ment that we have proposed, the ability to edit any definition makes the process of 
updating a sequence of definitions occur in a framework that is more intuitive than 
current environments i.e., Prolog, Standard ML, and Scheme. What we have not 
considered, however, is what is the meaning of two definitions in a sequence with the 
same name. This is called overloading. Overloading is an independent problem that 
has been studied separately [Ref. 3]. Overloading is beyond the scope of this paper, 
so the effect of multiple definitions with the same name has not been addressed in 
this thesis. Integrating the on-line system with overloading remains to be done. 

Investigating Sagiv et al.’s CAG to NCAG transformation is another area where 
further research is needed. Since SynGen is only capable of handling non-circular 
attribute equations the simple attribution in Chapter IV can not be implemented 
using SynGen. Work remains in determining whether the transformation of [Ref. 12] 
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can be applied to transform the circular attribution of Chapter IV, Another interest- 
ing research direction is exploring whether a fixed-point finding attribute evaluator 
can be produced automatically using the work of Farrow [Ref. 5]. 
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